Increasing numbers of security relevant communications and transactions are performed making use of today's communication networks. For example, an increasing number of bank transactions is carried out using worldwide data networks, allowing a user to be located independent of the location of the servicing institution. However, as a matter of fact, these international data networks may generally be accessed by anybody for any purpose and therefore data transactions such as the above banking transactions must be secured from unauthorized reading or deciphering of messages, passwords, acknowledgements and similar exchanged in connection with a transaction. The same may apply to e.g. subscribers of mobile phone services, accessing personal subscriber data over a network, research institutions exchanging data, or customers submitting credit card information over a network for purchases.
Many different approaches for securing data transmission via public networks are available, including, e.g., passwords, encryption and access control for example at a target server allowing only limited access and/or a limited set of actions allowed after access. However, the number of different types of available and necessary security measures and the number of different entities using different applications communicating over today's networks requires a substantial programming overhead when designing applications requiring security sensitive data transmissions over a network.
A security relevant data transmission over the network could be construed to follow the following steps.
An application running at a client server and planning to access a target (running at a server, e.g. at a bank office), which preferably is also executing an application, generates a message for transmission from the client to the server. As this message needs to be protected from unauthorized reviewing, the message will be encrypted for transmission and further, at the target certain access rights will be set in dependence on the application and the type of communication.
For a successful data transmission the application running at the client and the server must use, for example, the same set of encryption/decryption tools and therefore, the application at the client and the application used for receiving and processing the transmitted data at the target need to be adapted to each other. This however poses the problem that any type of application accessing a server or target needs to be fully compatible, including security aspects, with the software at the server. In case a large number of applications is designed to access the server, considerable programming efforts are necessary in order to keep the software at the server compatible to all applications.
To secure management applications in a distributed environment is one of the challenges designers and programmers of management applications have to take up and it is desirable to separate application specific routines, serving a transmission of information from the application to a server and security relevant activities, so that each group of activities may be executed by different entities of the system.
A number of different approaches to group application relevant actions and security relevant actions in a data communication over a network have been proposed, one of which is CORBA (Common Object Request Broker Architecture), as for example described in “CORBA”, Object Management Group, The CORBA Security Service Specification (Version 1.5), December 1998.
CORBA is a distributed platform layer available at entities communicating over a network, e.g., at a client and at an target. CORBA allows the execution of a number of service routines during a communication between a client running an application and a target or server, preferably also executing an application. Upon access by the client, the CORBA distributed layer invokes a predetermined set of security activities to be executed in connection with data transmitted from the client. This may include security association, access control, message protection, audit and similar. At the target side, the CORBA layer allows the execution of corresponding security activities in order to allow a successful data transmission from the client to the target. This may include, as before at the client, security association, access control, message protection, audit and similar.
The security or support activities executed by the CORBA layer are only invoked at access time, i.e., at a time the client accesses the network for a data transmission session. Further, security activities executed by CORBA are only dependent on the client but not designed to be dependent on a particular application, i.e., the security activities invoked are independent from the type application or communication the client is executing. For example, specific service routines related to a transfer of security relevant data to a bank (or from a bank server to a customer) or a transmission request from a client to a server of a telecommunication service, for retrieving subscriber relevant data, are not supported by CORBA.
With CORBA the application itself has to execute further security relevant functions concerning the application itself or the data transmission performed, including, e.g., access control, non-repudiation, audit, delegation and similar. Further, the target (also running an application) receiving a data transmission from the client application has to execute corresponding security activities, e.g. including target application access control, non-repudiation, audit, delegation and similar.
FIG. 5 shows a security service arrangement including a client 200, a target 210 and a distributed layer 220, e.g. a CORBA Common Object Request Broker Architecture layer. The client is running an application 201, and the target may run a corresponding application 211. As described above, in this scheme on one hand the distributed platform layer and on the other hand the client and the target execute security relevant activities, wherein the activities at the distributed platform layer level are application independent and the security activities executed at the client and at the target are application dependent security activities.
Even though this architecture provides an advantage over the initially described basic system, wherein all security or support relevant activities are performed at the client, more specifically, by the application running at the client, and at the target, i.e., the software or application running at the target and receiving the message from the client application, security or support relevant activities still need to be executed by the application running at the client and possibly at the application running at the target. In other words, security or support activities depending on the client accessing the network are moved from the application to the distributed platform layer constituting part of the network, while service or support routines dependent on the application running at the client (and target) remain on an application level.
Therefore, there is still a disadvantage with the system described with respect to FIG. 5, and security or support relevant aspects must be still treated by applications, still involving considerable programming efforts.
Because of the complexity of handling security measures it is desirable to put a specific component in charge of all security measures needed to run a management application in a secure manner.